Cashier configuration
With cashier payment products, they need to be flexibly configured for merchants to use, and the content displayed on the cashier can be flexibly configured to meet the needs of different products and different customers.HE Tuber Therefore the checkout uses the following configuration process.
After the merchant's application for network access is approved, the merchant will be configured with the "signing product" applied for. The contracting product is generally set in advance. You only need to associate the contracting product in the "Merchant Contracting Settings".

1. Contracted product configuration

Before providing merchant configuration, create a default payment method configuration. A product like an aggregated checkout counter may be composed of multiple groups of payment methods, so here we call this group of payment methods a "signed product".
Creating a contract product requires setting up a lot of things, including what gateway interface to use, transaction type, collection and payment account, default billing party, and setting their transaction attributes for each payment method.
From the picture above, we can see that payment methods can be grouped at multiple levels, so that they can be adapted to the classified display of multiple payment methods at the cashier, making it clearer for users to use. At the same time, each payment method can also set its sorting, whether to expand, logo, marketing copy, and a series of nuanced features such as how many cards are displayed by default in many cases when bound cards are bound.
Under normal circumstances, the contract products are set in advance, and the merchant can just select them directly when signing the contract; if the merchant has special needs, we can re-create one according to the template to meet the needs of different merchants.
It should be noted again that the contracted product configuration here is based on the product settings in the "Acquirer" scenario. The difference from the settings of ordinary non-licensed institutions lies in the settings of the account part. Because the acquirer has clearing and settlement qualifications and can do channel routing, it is not necessary to bind the corresponding channel to each payment method. It only needs to set up a merchant settlement account.
If it is a non-licensed institution, just change the "Account Settings Section" to the "Payment Channel" setting.

2. Merchant information management

After a merchant signs up to join the network and completes real-name authentication and pre-review, the merchant operator will create a payment product for the merchant here. Click Create to jump to the "Merchant Product Configuration" page to set up the product. After the setting is completed, the signed product will be linked to Merchants need to be associated so that merchants can access and use it. Of course, each configuration creation and modification needs to be re-examined before it can take effect, to avoid improper configuration that affects merchants' use.

3. Merchant product configuration

The purpose of merchant product configuration is to associate the merchant with the contracted product and modify the default parameters provided by the payment method to meet the customer's usage needs.
Figure 19: Merchant product configuration
From the picture we can see that a merchant can add multiple contract products, and each contract product can be set according to the parameters provided by the "original contract product" to meet the needs of different merchants for transactions, accounts and preferential activity participation.

5. Summary: Unified cashier design

1. Four-stage cashier design
The essence of the unified cashier lies in its "four-stage" design standard. It is the common language of all payers. Therefore, please keep these four interactive processes in mind and learn them. No matter how complicated the cashier design is, you can receive it. At your fingertips

2. Checkout capability view

While the cashier facilitates user operations and improves payment security, it also unifies various payment methods, making the docking very standardized and simple. Ping++ once proposed that "7 lines of code completes payment development" because it has seen through the essence of cashier design. The difference in payment lies in the two processes of placing an order and calling the cashier. The other processes are standard and reusable.

3. Use case model to draw inferences about other cases

Master the standard use case model of the checkout counter, and understand how the gateway, interface, and customer system achieve an overall closed loop in terms of four-stage design, unified interaction, and product configuration. After understanding this picture, you can handle any cashier design with ease.

4. Check out WeChat and Alipay interfaces

I can responsibly say that all domestic mobile checkout products are made with reference to the standards of these two companies. Therefore, we need to study more about the interface design of these two companies, especially the four interfaces of "ordering, calling the cashier, result notification and result query". Whether the product is good or not depends entirely on the depth of understanding of these four interfaces. ​​​​
​​​​Public account: Just talk about the product
This article was originally published by @ Gangge on Everyone is a Product Manager. Reprinting without authorization is prohibited.
The title picture comes from Unsplash, based on the CC0 agreement
The opinions in this article represent only the author's own. The Renren Product Manager platform only provides information storage space services.

Cashier configuration
Published:

Cashier configuration

Published:

Creative Fields